Localization: Parameter Tuning

Robot Motion (cont.)

So far, you have managed to make sure that both your robot and your maps are responsive. Which is great. But, the robot is still not following the right path to the goal.

Let's take a look at the costmap_common_params.yaml config file, and some of the parameters pre-defined for you (but not yet tuned) -

obstacle_range: 0.0
raytrace_range: 0.0
inflation_radius: 0.0

These parameters are very important in defining how your costmaps get updated with obstacle information and how your robot might respond to those while navigating.

obstacle_range - For example, if set to 0.1, that implies that if the obstacle detected by a laser sensor is within 0.1 meters from the base of the robot, that obstacle will be added to the costmap. Tuning this parameter can help with discarding noise, falsely detecting obstacles, and even with computational costs.
raytrace_range - This parameter is used to clear and update the free space in the costmap as the robot moves.
inflation_radius - This parameter determines the minimum distance between the robot geometry and the obstacles. Try setting a really high value for this parameter, and launch the project and select the global costmap selected. You will notice that the obstacles (the walls of the environment) seem to be "inflated" as can be seen below. An appropriate value for this parameter can ensure that the robot smoothly navigates through the map, without bumping into the walls and getting stuck, and can even pass through any narrow pathways.

To tune the above three parameters, we recommend the following approaches. In each case observe the differences to judge what value works best for this map -

Try setting a high value for inflation radius first, and have the robot navigate to your choice of a goal position. Then repeat the same with a low value.
Next, set the values for the obstacle and raytracing ranges and have the robot navigate to a position, again. Try to see if it can effectively navigate through the narrow passage and then take a turn.
Add an object, such as the Brick Box in Gazebo, as shown below. Try to observe how your previously selected parameter values behave with an object blocking part of the map. Note: This is only for testing purposes, and is not meant to be part of your project.

In each of the above cases, compare the results for both the global costmap and the local costmap.

Let's recap on what you have accomplished so far.

Task Feedback:

Excellent job!

Identifying and tuning these parameters is definitely hard, but it's also something a robotics engineer should be comfortable with in order to solve problems. While the above suggestions will get you started, they might not provide the best results at times. It is highly recommended that you go through the documentation corresponding to these packages, and the associated parameters and identify which ones could help improve your results. Here are some of these resources -

Robot Localization

Even though your robot is navigating adequately in the map, it's not producing good localization results. As you can see from the PoseArray in the image below, there is a lot of uncertainty around the robot's pose.

For the next part of the project, you will identify and tune parameters for your amcl node in the amcl.launch file, to achieve better results.

AMCL Parameters

The amcl package has a lot of parameters to select from. Different sets of parameters contribute to different aspects of the algorithm. Broadly speaking, they can be categorized into three categories - overall filter, laser, and odometry. Let’s cover some of the parameters that we recommend you start with or details to focus on.

Overall Filter

min_particles and max_particles - As amcl dynamically adjusts its particles for every iteration, it expects a range of the number of particles as an input. Often, this range is tuned based on your system specifications. A larger range, with a high maximum might be too computationally extensive for a low-end system.
initial_pose - For the project, you should set the position to [0, 0]. Feel free to play around with the mean yaw value.
update_min* - amcl relies on incoming laser scans. Upon receiving a scan, it checks the values for update_min_a and update_min_d and compares to how far the robot has moved. Based on this comparison it decides whether or not to perform a filter update or to discard the scan data. Discarding data could result in poorer localization results, and too many frequent filter updates for a fast moving robot could also cause computational problems.

Laser

There are two different types of models to consider under this - the likelihood_field and the beam. Each of these models defines how the laser rangefinder sensor estimates the obstacles in relation to the robot.

The likelihood_field model is usually more computationally efficient and reliable for an environment such as the one you are working with. So you can focus on parameters for that particular model such as the -

laser_*_range
laser_max_beams
laser_z_hit and laser_z_rand

Tuning of these parameters will have to be experimental. While tuning them, observe the laser scan information in RViz and try to make sure that the laser scan matches or is aligned with the actual map, and how it gets updated as the robot moves. The better the estimation of where the obstacles are, the better the localization results.

Odometry

odom_model_type - Since you are working with a differential drive mobile robot, it’s best to use the diff-corrected type. There are additional parameters that are specific to this type - the odom_alphas (1 through 4). These parameters define how much noise is expected from the robot's movements/motions as it navigates inside the map.

**Note: ** The odometry information for this project is received directly from Gazebo, and is equivalent to the ground truth value (no noise expected). So, you need not have to tune these parameters and can leave them at their default values. But feel free to experiment with some values and see if you notice any changes.

Important: The above set of parameters should help you get started, however they aren't the only ones that can improve your results. You are encouraged and required to go through the documentation, identify which parameters might help you improve your localization results, and experiment with them. All the remaining parameters and corresponding documentation can be found on the ROS wiki's amcl page.

Identifying and tuning all these parameters can take time and effort. But don't worry. Based on the information and resources provided uptil now, you are well-equipped to tackle the problem head-on! Make sure to discuss your approaches with your fellow students in the ND Slack, and to reach out to your mentor for any further help.